我們已經知道 RAG 讓 AI 學會了開書考，那接下來的問題是：這本『參考書』（知識庫）是如何被製作出來的？AI 又是如何以毫秒級的速度，從成千上萬頁的資料中，精準翻到正確的那一頁？

RAG 準備階段 (Indexing): 打造一本高品質的 AI「參考書」

在我們深入探討如何讓大型語言模型（LLM）回答特定領域的問題之前，必須先為它準備好一本高品質、易於查閱的「參考書」。這個過程在 RAG（Retrieval-Augmented Generation）架構中被稱為「準備階段」或「索引（Indexing）階段」。這是一個「離線」的準備工作，但它卻是整個 系統成功的基礎建設。這個階段的核心任務，是將擁有的龐大且多樣的原始資料，轉換成 AI 能夠理解並能高效檢索的格式。

第一步：資料載入與前處理 (Data Loading & Preprocessing)

第一步是將散落在各地的知識寶藏匯集起來。現代企業的資料來源非常多樣，非純文字檔案所能涵蓋。一個強大的 RAG 系統必須能夠處理各式各樣的資料格式。這就像一位博學的學者，不僅能閱讀書籍，還能解讀地圖、分析報告、甚至觀看教學影片。

常見的資料來源包括：

• 文件檔案: PDFs (研究報告、手冊), DOCX (合約、會議記錄), PPTs (簡報)。
• 網頁內容: 透過網路爬蟲抓取的公司官網、產品說明、技術部落格。
• 結構化資料: 存放在 SQL 或 NoSQL 資料庫中的使用者數據、產品規格表。
• 非結構化資料: 純文字檔 (.txt), Markdown (.md) 等。

為了應對這種複雜性，通常不需從零開始造輪子。例如像 LangChain 和 LlamaIndex 這類框架提供了豐富的「文件載入器」（Document Loaders），能輕易將內容讀取轉換為統一為框架各自的 Document/Node 結構（LangChain: page_content+metadata；LlamaIndex: text+metadata），再交由 chunking 與 embedding 流程使用。

第二步：文本切塊 (Text Chunking / Splitting)

把所有資料都轉換成純文字後，下一個問題接踵而至：我們能把一本 500 頁的 PDF 整本直接丟給 AI 閱讀嗎？答案是否定的。

背後的原因是大型語言模型（LLM）有其「上下文視窗」（Context Window）的限制。可以把上下文視窗想像成人類的「短期記憶」或「專注力範圍」，模型一次能夠處理的文本長度是有限的（例如，幾千到幾十萬個 tokens 不等）。如果強行輸入超過限制的內容，模型不僅會報錯，更無法理解文章的核心思想。

因此，將長篇大論切分成一個個有意義、有連貫性的「小段落」（Chunks）便至關重要。一個好的切塊策略，能確保每個段落都包含一個相對完整的概念，避免在檢索時只得到破碎的資訊。

技術策略演進：

1. 固定大小切塊 (Fixed-size Chunking):
   • 作法： 這是最直觀的方法，例如設定每 500 個字元為一個區塊。
   • 優點： 簡單、快速。
   • 缺點： 容易粗暴地切斷一個完整的句子或段落，導致語意不連貫，就像把「台灣最高的山是玉山」硬生生切成「台灣最高的山」和「是玉山」兩個片段。
2. 遞迴字元切塊 (Recursive Character Text Splitting):
   • 作法： 設定一組分隔符號的優先級，例如 ["\n\n", "\n", " ", ""] (段落 -> 換行 -> 空格 -> 字元)。它會優先嘗試用「段落」來切分，如果切出來的區塊仍然太大，它會退一步，改用「換行符」來切，依此類推，直到每個區塊都小於設定的大小。
   • 優點： 最大程度地尊重了原文的結構，盡力保持語意的完整性。這是目前最常用且效果不錯的策略。
3. 語意切塊 (Semantic Chunking):
   • 作法： 不再依賴固定的規則或標點符號，而是利用另一個語言模型來「閱讀」文本，並判斷語意的邊界在哪裡。它會尋找句子之間語義關聯性的「斷點」，在這些地方進行切分。
   • 優點： 能確保每一個切塊都是一個高度內聚、獨立完整的概念單元。例如，一段在講「安裝步驟」的內容和下一段講「故障排除」的內容，即使中間沒有明顯的段落分隔，語意切塊也能準確地將它們分開。

第三步：向量化 (Embedding) - 將文字轉換成 AI 能理解的語言

有了一堆大小適中、語意完整的文本區塊，但對電腦來說，這些仍然只是無意義的字串。我們需要將它們翻譯成 AI——也就是數學模型——能夠理解的語言。

此時就會需要「嵌入模型」（Embedding Model）。你可以將它想像成一個精通多國語言的「語意翻譯機」。它的任務不是將一種人類語言翻譯成另一種，而是將任何語言的「意義」（Semantic Meaning）轉換成一個由數百甚至數千個數字組成的「向量」（Vector）。

這個向量可以被視為這段文字在一個高維度語意空間中的「座標」。在這個空間裡，存在一個奇妙的規律：意思越相近的文字，它們的向量座標也越接近。 例如，「貓」和「小貓」的座標會非常靠近，「貓」和「狗」的座標會比較近，而「貓」和「汽車」的座標則會相距甚遠。

主流 Embedding 模型：

• 專有模型 (Proprietary Models):

  • OpenAI: text-embedding-3-small / text-embedding-3-large / text-embedding-ada-002 是目前業界廣泛使用的模型，效果卓越，但需要付費調用 API。

  建議首選 text-embedding-3 系列；ada-002 為前代，相容但逐步淡出。

• 開源模型 (Open-Source Models):

  • Hugging Face Hub: 這裡有成千上萬個由社群貢獻的開源模型。
    • all-MiniLM-L6-v2: 一個輕量級、高效能的通用英文模型。
    • bge-large-zh: 由中國智源研究院開發，定位為「中文（以簡體為主）的強力嵌入模型」，繁體需求改推 BGE-M3 或 multilingual-E5。

第四步：儲存與索引 (Storing & Indexing) - 建立一個高效的「圖書館索引系統」

經過向量化後，我們現在擁有了數十萬甚至數百萬個文本區塊的「向量座標」。接下來，我們需要一個專門的系統來儲存它們，並且能夠在使用者提問時，以毫秒級的速度找到最相關的幾個向量。此時就會需要使用到「向量資料庫」（Vector Database）。

傳統資料庫擅長精確匹配（例如，尋找 ID = 123 的使用者），但它們無法有效地回答「哪個向量和這個最像？」這類問題。向量資料庫則是為這種「相似度搜尋」（Similarity Search）而生的。它就像一個超級高效的圖書館索引系統，當你給它一個問題（也被轉換成向量後），它能立刻告訴你哪些書（文本區塊）的內容與你的問題最相關。

主流向量資料庫工具：

• ChromaDB: 一款開源、輕量級的向量資料庫，非常適合入門和中小型專案，可以快速在本地部署。
• Pinecone: 一種高效能的託管式 (Managed) 向量資料庫服務，適合需要處理海量資料和高併發請求的企業級應用。
• FAISS (Facebook AI Similarity Search): 由 Meta AI 開發的一個底層函式庫，而非一個完整的資料庫。它提供了多種高效的相似度搜尋演算法，是許多其他向量資料庫的核心。
• Weaviate: 另一款強大的開源向量資料庫，支援圖形查詢（GraphQL）並具備良好的擴展性。

為什麼向量資料庫能這麼快？它們並不是一個個去比較所有向量的距離（那樣太慢了）。其背後採用了如 HNSW (Hierarchical Navigable Small World) 這類的「近似最近鄰」（Approximate Nearest Neighbor, ANN）演算法。

HNSW 的思想類似於建立一個多層次的「高速公路網路」。在高層次，它只連接相距很遠的節點，可以快速跳躍到目標向量所在的大致區域；然後在較低的層次中，進行更精細的區域性搜尋，直到找到最接近的幾個鄰居。這種方法雖然不保證 100% 找到絕對最近的點，但在準確率和速度之間取得了絕佳的平衡，足以滿足絕大多數 RAG 應用的需求。